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ABSTRACT 



A security architecture has been developed in which a single 
sign-on is provided. Session credentials are used to maintain 
continuity of a persistent session across multiple accesses to 
one or more information resources, and in some 
embodiments, across credential level changes. Session cre- 
dentials are secured, e.g., as a cryptographically secured 
session token, such that they may be inspected by a wide 
variety of entities or applications to verify an authenticated 
trust level, yet may not be prepared or altered except by a 
trusted authentication service. Some embodiments of the 
present invention associate trust level requirements with 
information resources. Authentication schemes (e.g., those 
based on passwords, certificates, biometric techniques, 
smart cards, etc.) are associated with trust levels, and in 
some embodiments, with environmental parameters. For 
example, in one configuration, a login service obtains login 
credentials for an entity commensurate with the trust level 
requirements) of an information resource (or information 
resources) to be accessed and with environment parameters 
that affect the sufficiency of a given credential type. Once 
login credentials have been obtained for an entity and have 
been authenticated to a given trust level, session credentials 
are issued and access is granted to information resources for 
which the trust level is sufficient. Advantageously, by using 
the session credentials access is granted without the need for 
further login credentials and authentication. In some 
configurations, session credentials evidencing an insufficient 
trust level may be remedied by a session continuity preserv- 
ing upgrade of login credential. 
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ACCESS MANAGEMENT SYSTEM AND re-authenticated when accessing an order status system. 

METHOD EMPLOYING SECURE Worse still, a set of individualized solutions is typically only 

CREDENTIALS as S°°d as Ike weakest solution. A weak solution may allow 

an enterprise to be compromised through a low security 
5 entry point. 

BACKGROUND Another problem with individualized solutions is a veri- 

1 i"" i-i c iL ¥ table explosion in the number of access controls confronting 

1. Field of the Invention r A j . . j * j ■ 

a user. As more and more business is conducted using 

The invention relates to information security, and more computer systems, users are confronted with multiple iden- 

particularly, to systems and method for improving the secu- tifiers and passwords for various systems, resources or levels 

rity of information transactions over networks. 0 f access. Administrators are faced with the huge problem of 

2. Description of the Related Art issuing, tracking and revoking the identifiers associated with 
The internet has become an important medium for infer- their "sra. ^ the <(user " community grows to include 

mation services and electronic commerce. As the internet vendors, customers, potential customers, consultants and 

has been commercialized, organizations initially established „ others m addition to employees, a huge "id explosion" faces 

their presence in cyberspace by making information administrators. Furthermore, as individual users are them- 

(typicaUy static, non-sensitive promotional information) C °^ r ° n * ed wth t large <>* identifiers and 

., i_, 1. jr «l i passwords, adherence to organizational security policies 

available on resources well removed from the operational r , , ... & , . . / i .u 

. P c , „ . . r Ci such as password restnctions and requirements (e.g., length, 

infrastructute of the organization. Security issues were often ctmticl { T and/or case complexity, robustness to dictionary or 

addressed by plating publicly accessible resources (e.g 20 easflyi<soeltaillabte information attack, frequency of update, 

web servers) from more sensitive assets using firewall ^ be reduced M ^ ir(j mor( , ords _ 

techniques. As long as the publicly accessible information ^ individuals have 50 or cannot help 

and resources were relatively non-sensitive and user inter- . . , nt _ ' ™„ tn „„^ m u^, \~a , ' 

. . . . - . . . . but write down or create easy-to -re member, and easy -to - 

actions with such information and resources was not mission . i 

, . . compromise, passwords, 

critical, relatively simple firewall techniques were adequate, 25 

Though information and resources outside the firewall were SUMMARY 

at risk, the risk could generally be limited to non-proprietary Accordingly, a security architecture has been developed 

information that was easily replaceable if compromised. in which a single sign-on is provided. Session credentials are 

Proprietary information and systems critical to day-to-day use d t 0 maintain continuity of a persistent session across 

operations were sheltered behind the firewall and informa- 30 multiple accesses to one or more information resources, and 

tion flows across the firewall were filtered to exclude all but m some embodiments, across credential level changes. Ses- 

the comparatively non-threatening services such as elec- s [ on credentials are secured, e.g., as a cryptographically 

tronic mail. secured session token, such that they may be inspected by a 

However, as the internet has become more pervasive, and wide variety of entities or applications to verify an authen- 

as the sophistication of tools and techniques has increased, 35 ticated trust level, yet may not be prepared or altered except 

several aspects of the security environment have changed by a trusted authentication service. Some embodiments of 

dramatically. First, businesses have recognized the power of the present invention associate trust level requirements with 

information transactions that more tightly couple to opera- information resources. Authentication schemes (e.g., those 

tional data systems, such as order processing, inventory, based on passwords, certificates, biometric techniques, 

payment systems, etc. Such transactions include electronic 40 smart cards, etc.) are associated with trust levels, and in 

commerce with direct purchasers or consumers (e.g., some embodiments, with environmental parameters. For 

browsing, selecting and purchasing of books by members of example, in one configuration, a login service obtains login 

the public from an on-line bookseller) as well as supply credentials for an entity commensurate with the trust level 

chain and/or business partner interactions (e.g., automated requirements) of an information resource (or information 

just-in-time inventory management, customer-specific 45 resources) to be accessed and with environment parameters 

pricing, availability and order status information, etc.). that affect the sufficiency of a given credential type. Once 

Commercially relevant transactions increasingly require login credentials have been obtained for an entity and have 

information flows to and from secure operational systems. been authenticated to a given trust level, session credentials 

Second, even information-only services are increasingly are issued and access is granted to information resources for 

mission -critical to their providers. Corporate image can be 50 which the trust level is sufficient. Advantageously, by using 

adversely affected by unavailability of, or degradation the session credentials access is granted without the need for 

access to, otherwise non-sensitive information such as cus- further login credentials and authentication. In some 

tomer support information, product upgrades, or marketing configurations, session credentials evidencing an insufficient 

and product information. Because many businesses rely trust level may be remedied by a session continuity preserv- 

heavily on such facilities, both unauthorized modification 55 ing upgrade of login credential. 

and denial of service represent an increasing threat. in one embodiment in accordance with the present 

Individual information service or transaction system typi- invention, a session credential includes a principal identifier 

cally exhibit differing security requirements. While it is uniquely identifying a principal and an encoding of autho- 

possible to field individualized security solutions for each rization accorded by the security architecture after prior 

information service or transaction system, individualized 60 authentication of a login credential corresponding to the 

solutions make it difficult to maintain a uniform security principal. The principal identifier and authorization encod- 

policy across a set of applications or resources. Furthermore, ing are cryptographically secured and allow the security 

individualized solutions tend to foster incompatible security architecture to evaluate sufficiency of the authorization for 

islands within what would ideally be presented to consumers access to the one or more information resources without 

or business partners as a single, integrated enterprise. For 65 re-authentication of the login credentials. In one variation, 

example, a user that has already been authenticated for the session credential is supplied external to the security 

access to an order processing system may unnecessarily be architecture as a session token. 
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In another embodiment in accordance with the present Therefore, to aid persons of ordinary skill in the art in 

invention, a session token is provided for transfer between understanding the full scope of the invention, some of that 

a client entity operating on behalf of a principal and a terminology is now defined, 
security architecture controlling access to an information 

resource. The session token includes a principal identifier 5 Glossary 
uniquely identifying the principal and an indication of 

authorization level accorded by the security architecture Access Management: Systems, methods and techniques 

after prior authentication of a login credential corresponding for controlling use of information resources. Typically, 

to the principal. The principal identifier and authorization access management systems employ both authentication and 

level indication are cryptographically secured and allow the 1Q authorization to control access to information resources, 

security architecture to evaluate sufficiency of the authori- Authentication: A process used to verify the identity of an 

zation for access to the information resource without entity. As typically implemented, an authentication method 

re-authentication of the login credentials. ^ employed to verify the identity of a user or object based 

In still another embodiment in accordance with the on a cre dential supplied by the user or object, 

present invention, a method of providing authorization veri- A #u . A c , . . . ... 

g 4- • •* ~~ . ii* * 15 Authorization: A process for determining whether an 
ncation in a security architecture controlling access to one or JJ . . . , ^ r - & , 
more information resources includes obtaining a login ere- ldentlt y 15 permitted to perform some action such as access- 
dential and authenticating a principal thereby and issuing a m & a resource. Typically, an identity will be authenticated, 
cryptographically secured session credential. The crypto- thou & h m some configurations certain identities need not be. 
graphically secured session credential encodes at least an Credential: Evidence:of identity used to authenticate an 
identifier for the principal and a first authorization accorded 20 entity. Exemplary credentials types include passwords, cer- 
based on the authenticating. For plural requests for accesses tificates or other encrypted indicia based on asymmetric, 
to the one or more of the information resources, the method symmetric, public, private, or secret key technologies, one- 
further includes selectively allowing access based on suffi- time passwords, biometric indicia such as by retinal scan, 
ciency of the first authorization encoded by the crypto- voice print, finger print, etc., and possession based indicia 
graphically secured session credential for access to the one 2 5 such as smart cards, Enigma cards, keys, etc. In some 
or more of the information resources, wherein the selective realizations, credentials may be associated with users, 
allowing is performed without additional login credential scssioilSf functional objects, etc. 

"Si? another embodiment in accordance with the Digital Signature: A transformation of a message using an 

present invention, an information access control facility 30 symmetric cryptosystem such that a person having the 

includes an application proxy and means responsive to the mitial message and the signer s public key can accurately 

application proxy. The application proxy is for receiving an determine whether the transformation was created using the 

access request targeting one of the information resources, private key that corresponds to the signer's public key and 

extracting a cryptographically secured session token from whether the message has been altered since the transforma- 

the access request, and selectively proxying the access tion was made. 

request. The means responsive to the application proxy is for 35 Entity: A user or object, including data objects and/or 

evaluating sufficiency of an authorization encoded in the functional objects such as applications, components, 

cryptographically secured session token for access to the modules, services, processes, threads, etc., as well as instan- 

targeted information resource. tiations thereof. In some configurations, only user entities 

BRIEF DESCRIPTION OF THE DRAWINGS 40 (typically, the human principal interacting with a software 

The present invention may be better understood, and its P ro S ram ° r °° wh T ose b f alf a s ° ftware a S eDl P ur ?° rts loac j) 

numerous objects, features, and advantages made apparent are considered. In other configurations, entities include 

to those skilled in the art by referencing the accompanying functional objects without an associated human principal, 

drawings. Tb e identity of an entity may be authenticated using a 

FIG. 1 is a block diagram illustrating information flows 45 crcdential - 

between components in a security architecture employing Session: A period and collection of states spanning one or 

secure session credentials in accordance with an exemplary rnore interactions between an entity and an information 

embodiment of the present invention. environment. As used herein a session may span multiple 

FIG. 2 is a flow chart illustrating operation of a security interactions with multiple resources of the information envi- 

architecture employing secure session credentials in accor- 50 ronment and, in some configurations, may span multiple 

dance with an exemplary embodiment of the present inven- information access protocols (e.g., HTTP, FTP, telnet, etc.). 

t i on A session has a beginning and an end. During its existence, 

FIG. 3 illustrates interactions between functional compo- a ses ^ has state - ^wed herein, the term session connotes 

nents in a functional decomposition of a security architec- a greater persistence than as sometimes used to describe the 

ture employing secure session credentials in accordance 55 period of a "session layer" protocol interaction, which m the 

with an exemplary embodiment of the present invention. case of v Some protocols, such as HTTP, is generally very 

FIG. 4 illustrates relations between login credentials, s o - iv . 

session credentials and a cookie encoding of a session token Sin ^ e Sigrj _ on Security Architecture 
in accordance with an exemplary embodiment of the present 

invention. 60 FIG. 1 provides an overview of major interactions 

The use of the same reference symbols in different draw- between components for an exemplary security architecture 

ings indicates similar or identical items. m accordance with the present invention. As illustrated in 

FIG. 1, a client application, e.g., a browser 170 operated by 

DESCRIPTION OF THE PREFERRED a mte racts with the security architecture via a gate- 

EMBODIMENT(S) 65 j^per and entry handler component 110 and a login com- 

Some terminology used in this specification has meaning ponent 120. Gatekeeper and entry handler component 110 

particular to the context of embodiments described herein. provides an entry point for external client applications 
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requesting access to enterprise applications and/or resources 
190, including e.g., information resources 191, 192 . . . 193, 
for which access management is provided by the security 
architecture. Using facilities provided by a session manage- 
ment component 160, an authorization component 140, an 
authentication component 130, an identification component 
150, and login component 120, the gatekeeper/entry handler 
component 110 allows, redirects or refuses access requests 
in accordance with a security policy. 

Individual information resources typically have differing 
security requirements. In addition, individual types of access 
to a single information resource may have differing security 
requirements. Nonetheless, a given level of security may be 
sufficient for more than one of the information services or 
access types. For example, information resource 191 may 
include a product information service for providing general 
information such as product descriptions or data sheets to 
the public, while information resource 192 includes an order 
processing system for an eCommerce site. Information 
resource 193 may include functions for supply chain inter- 
actions such as access to inventory information or current 
selling price information. Both the product information 
service and order intake functions of the eCommerce may 
operate with similar security requirements, e.g., allowing 
access by minimally authenticated, non-hostile entities. On 
the other hand, supply chain functions may require a higher 
level of security. Order status functions of the order pro- 
cessing system may require a mid -level of security 

Login component 120, operating in conjunction with 
gatekeeper/entry handler component 110 and other compo- 
nents of the security architecture, provides a single sign-on 
interface for access to enterprise applications and/or 
resources 190. In an exemplary embodiment, security 
requirements are expressed in terms of trust levels and login 
component 120 obtains login credentials for an entity 
requesting access to one of the enterprise applications and/or 
resources 190. The login credentials obtained are selected 
from a set of credential types that, if authenticated, are 
sufficient to achieve the trust level requirement of an appli- 
cation or information resource to be accessed. Without 
limitation, typical login credential types and associated 
authentication mechanisms include those based on 
passwords, certificates, biometric techniques, smart cards, 
etc. Other credential types and associated authentication 
mechanisms are described elsewhere herein. 

In some embodiments in accordance with the present 
invention, gatekeeper/entry handler component 110 queries 
authorization component 140 to obtain authorization for 
access to a particular requested enterprise application or 
information resource by the requesting entity (e.g., the 
browser user). If the entity requesting access has not yet 
been authenticated to the trust level required for the par- 
ticular access to the particular enterprise application or 
information resource requested, authorization component 
140 may indicate that the access request is to be redirected 
to login component 120 so that login credentials may be 
obtained and authenticated to a particular trust level. If, on 
the other hand, login credentials have already been obtained 
for the requesting entity and the requesting entity has been 
authenticated using the obtained credentials such that the 
required trust level has been achieved, the access will 
typically be allowed without the need for further login 
credentials and authentication. In certain circumstances, 
authorization component 140 may indicate that the access is 
to be refused. For example, authorization component 140 
may be programmed to perform more stringent testing 
beyond a trust level requirement. In an exemplary enterprise 
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tool configuration, a desired security policy may dictate that 
a salary tool is accessible only from with a company's 
internal network. No level of authenticated trust may be 
sufficient to access such a tool from outside company 

5 network. To facilitate implementation of such a security 
policy, authorization component 140 could refuse access 
based on environment parameters indicating a session origi- 
nating outside the company's internal network. 

Of note, in certain embodiments in accordance with the 

10 present invention, the mapping of login credential types and 
authentication mechanisms to trust levels is influenced by 
environment information such as time of request, source of 
request, connection speed, and/or client application (e.g., 
browser) environment information. In this way, even with a 
static set of mapping rules, the set of credential types and 

15 authentication mechanisms suitable to support a given trust 
level may vary based on environment information. In 
general, mapping rule dependencies are based on perceived 
variations in threat characteristics and/or requesting entity 
capabilities. In some embodiments in accordance with the 

20 present invention, gatekeeper/entry handler component 110 
is the authority on environment information for a particular 
requesting entity. 

In some embodiments, mapping rules may be dynami- 
cally varied. For example, if a particular login credential 

25 type and/or authentication method is deemed insecure (e.g., 
because compromised or because of a changing threat 
profile), the trust level mappings can be updated and have 
enterprise- wide effect. In addition, several other advantages 
are achieved by defining the authentication requirement 

30 interface between enterprise applications and/or resources 
and the security architecture in terms of required trust levels, 
rather than in terms of particular credential types and 
authentication methods. First, single sign-on configurations 
are facilitated using an enterprise-wide credential obtaining, 

35 authentication and session tracking infrastructure. Second, 
authentication requirements may be enforced uniformly in 
accordance with an enterprise-wide security policy and with 
reduced vulnerability to a lax security implementation by 
any particular information resource. Third, credential types 

40 and authentication methods can be added, deleted, or 
mapped to a new trust level, all without modification of 
enterprise applications and resources. Of course, all advan- 
tages need not be achieved in any particular implementation. 
In certain embodiments in accordance with the present 

45 invention, a credential upgrade facility is provided. In 
response to an access request from an entity for which login 
credentials have already been obtained and authenticated, 
but for which the obtained and authenticated log in creden- 
tials are insufficient for the trust level associated with the 

50 requested access, authorization component 140 may indicate 
that the access request is to be redirected to login component 
120 so that sufficient login credentials may be obtained and 
authenticated to the required trust level. Of note, credential 
upgrade facilities in accordance with certain embodiments 

55 of the present invention allow upgrade without loss of 
session continuity. 

In addition to the obtained login credentials, some con- 
figurations in accordance with the present invention employ 
session credentials as a mechanism for evidencing prior 

60 authentication of obtained login credentials and for binding 
individual transactions to a particular session. In some 
configurations, session credentials are also employed in a 
session token form advantageous for transactions external to 
the security architecture. In an exemplary realization, ses- 

65 sion tokens are encoded for supply to browsers as cookies, 
FIG. 4 illustrates relationships between exemplary login 
credential, session credential and session token objects. 
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As described above, login credentials (e.g., represented in 
a form such as exemplary login credentials structure 410) 
are obtained for a client entity. Typically, login credentials 
encoded in login credentials structure 410 are obtained from 
a principal via browser client and serve as evidence that the 
principal (e.g., a human user) is entitled to a particular 
identity. Accordingly, login credentials structure 410 
encodes a userld and a domainld within which the userld 
should uniquely correspond to a principal. Specific login 
credentials, e.g., a password, a certificate, results of a 
bio metric process, a response to an Enigma challenge or 
results of a smart card interrogation, etc. are encoded in 
login credentials structure 410, as a tagged value. An authen- 
ticationScheme is specified and creation time may be 
encoded to limit replay attacks. In the implementation of 
FIG. 4, login credentials structure 410 is encrypted using the 
public key of an authentication service (e.g., of authentica- 
tion component 130). Because the key is pubtic, any 
component, even untrusted components may encrypt login 
credentials for provision to authentication component 130, 
while only authentication component can decrypt the 
encrypted login credentials using its private key. In some 
configurations, secure transfer protocols, e.g., SSL, are 
employed to secure login credentials between a client entity 
such as browser 170 and the security architecture while 
encryption with a public key of an authentication service is 
performed within the security architecture, e.g., at login 
component 120. In other configurations, encryption with a 
public key of an authentication service may be performed at 
the client entity. 

If the encrypted login credentials provided to an authen- 
tication service are determined to be authentic, session 
credentials are issued. In the implementation of FIG. 4, 
session credentials are embodied in a form such as exem- 
plary session credentials structure 420. Encrypted and clear 
text portions (421 and 422) of session credentials structure 
420 allow contents of the session credential to be read by 
anyone and changed by no one (except the authentication 
service possessing a private key). Contents of encrypted 
portion 421 correspond to that clear text portion 422 but are 40 
encrypted using the private key of the authentication service 
(e.g., of authentication component 130). Of note, principal 
ids, authorizations and other contents encoded in the session 
credential may be read by components of the security 
architecture, and in some embodiments by components 45 
external to the security architecture. Such components can 
verify the authenticity of information stored in clear text 
portion 422 using encrypted portion 421 and a public key 
corresponding to the private key of the authentication ser- 
vice. Of note, the information contained in a session cre- 
dential is generally not sensitive. What is sensitive is the 
state of the information. Therefore, security architectures 
employing facilities described herein ensure that informa- 
tion contained in the session credential is provably constant 
once set by an authentication service. By using the public 
key of the authentication service, which will in general be 
freely available, together with the encrypted information, 
any application can read the information (e.g., in free text) 
and ascertain that the session credential was created by the 
authentication service and that the session credential has not 
been tampered with. Assuming that the authentication ser- 
vice's private key has not been compromised, tampering 
with the session credential will result in a decryption failure. 

In an alternative implementation (not shown), session 
credentials may be digitally signed and verified by a public 
key corresponding to a private key. In such an alternative 
implementation, the digital signature also allows contents of 
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the session credential to be read by anyone and changed by 
no one. For some configurations, the implementation of FIG. 
4 is preferred because encrypted portion 421 can be used as 
an externally supplied session token. Such a session token 
representation is a compact representation of the session 
credential particularly appropriate for encoding as a cookie 
placed at a browser and returned with subsequent access 
requests. 

Referring again to session credentials structure 420, a 
session id, a principal id, a trust level, group ids, a creation 
time and an expiration time are encoded in both in encrypted 
portion 421 and clear text portion 422. The session id is a 
unique identifier for a persistent session maintained by the 
security architecture. In implementations in which credential 
upgrade is provided or in which a session credential expi- 
ration and refresh is provided, multiple successively issued 
session credential instances may encode the same session id 
and correspond to the same persistent session. Principal id 
encodes an identifier for a principal to which the security 
architecture has resolved login credentials. For example, a 
login credential including a username jdoe and a password 
corresponding to jdoe may be resolved by the security 
architecture to a unique principal id associated with John. Q. 
Doe of the shipping and receiving department, having an 
employee badge number of 12345, etc. 

In some embodiments, a trust level encodes the authori- 
zation level to which a principal has been authenticated. In 
such embodiments, the encoded trust level serves as a basis 
for evaluating whether a principal associated with the ses- 
sion credentials has been authenticated to a sufficient level 
for access to a requested resource. For example, a trust leveli 
of 5 may be sufficient for access to information resources 
having a trust level requirement of 5 or less. Trust levels 
offer an attractive decoupling of authorization levels and 
authentication methods as described elsewhere herein. 
However, in some embodiments, an authorization encoding 
may establish that a principal has been authenticated using 
a particular authentication mechanism. In either case, an 
authorization (e.g., encoded as a trust level) in a crypto- 
graphically secured session credential allows the security 
architecture to authorize accesses based on prior authenti- 
cation of a login credential and without involvement of the 
authentication service. 

Group ids can be used to grant or limit authorization scope 
based on group membership. Typically, session credentials 
serve as evidence of prior authentication and authorization 
for multiple accesses to information resources controlled by 
the security architecture. However, session credentials may 
be replaced on a login credential upgrade as described 
elsewhere herein. In addition, session credentials of limited 
temporal validity may be refreshed by periodic replacement. 
In the configuration of session credentials structure 420, 
creation time and expiration time allow the security archi- 
tecture to improve resistance to replay attacks. Session 
credentials typically have a relatively short expiration time 
(e.g., 15 minutes from creation or less) and underlying login 
credentials will be reauthenticated prior to expiration of the 
session credential. Assuming that the underlying login 
credentials, which are stored under the public key of authen- 
tication component 130, remain valid, authentication com- 
ponent 130 will issue a replacement cryptographically 
secured session credential (e.g., as session credentials struc- 
ture 420). Depending on then current trust level mappings 
and, in some configurations, depending on then current 
environment parameters, the authorization accorded by the 
security architecture and encoded as a trust level may differ 
from that encoded in the session credential replaced. If a 
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principal id or login credential has been revoked, reauthen- connections, environment information such as line speed 

tication may fail and a user may be prompted to supply a and low-level line encryption are ascertained. Additional 

sufficient login credentials as described elsewhere herein. information, such as source number (e.g., from caller id 

Session id and principal id will typically remain the same for information or based on a callback configuration), signaling 

successive session credentials associated with a single per- 5 type ( e -g-» POTS or digital ISDN), etc., may also be 

sistent session. obtained. For network connections, similar environment 

..... . - , , information (e.g., source network and/or node, Virtual Pri- 

As previously described one advantage of the approach yate Netwo ^ *^ encryption, etc.) may be 

employed in , session credentials structure 420 is tha frQm ^ , hem ^ lves or ^ y Qn , 

encrypted portion 421 may also be employed as a compact . • • / *• i . _*\ 

r r 4 f t / Am e - -i *• i f m particular entry point (e.g., a particular router or port). More 

session token representation 430 of session credential for 30 r „ * r ; ? , r „ ,; 1ft \, . 

. . T F ... 4 . , ... in/- generally, gatekeeper/entry handler component 110 obtains 

use as a cookie. In one embodiment in accordance with FIG. & ... • c *• u . i rc 

a * j a^ ■ jj and/or maintains mformation such as connect location (if 

4 encrypted portion. 421 is a string .encoded represent.™ ascertainable)> , d informalion sucb „ requesl ^ 

of approximately 200 characters which may be placed at a , t /j . * / c ui ■ u *u *u 

, rr , ' r _ . *\ • t date, session start tune/date, etc. (preferably in both the 

browser (e.g via transfer 5, 23 or 23A of FIG. 1) using a set ^ ^ fraffle Qf KfeKa(x ^ ^ architec . 

cookie directive 

hire or requested information resource's frame of reference, 

Exemplary Configuration * «««tioD » ascertainable) and client type and/or capabiJi- 

ties (e.g., browser type and Java Development Kit (JDK) 
Referring to FIG. 1, an entity (e.g., a browser 170 level). In some configurations, information on line speed, 
operated by a user) interacts with enterprise applications 2Q origination point (e.g., inside or outside of a corporate 
and/or resources 190 and the security architecture via a network), browser type, encryption capability, number of 
gatekeeper/entry handler component 110 and a login com- hops, latency, system type, etc. may be gathered. Such 
ponent 120. In general, a wide variety of entities, including information is used in some configurations for mapping 
human users operating browser and/or non-browser client particular authentication mechanisms to trust levels and for 
applications as well as automated agents and systems, may 25 authorization decisions. Environment information is gener- 
interact with enterprise applications and/or resources 190 ally packaged into a data structure that is associated with a 
and the security architecture as described herein. client session. Other components of the security architecture 
Furthermore, a variety of information resource identification may add additional client environment information, such as 
schemes, such as by Uniform Resource Locator (URL), authentication strength or current trust level, 
resource address, identifier or namespace designation, may 30 Gatekeeper functionality (e.g., in gatekeeper/entry nan- 
be employed. However, for purposes of illustration and not dler component 110) checks whether a session is already 
limitation, an exemplary interaction involving a browser and associated with the incoming request. Although other tech- 
information resources identified by URL is described in niques are possible, in some configurations in accordance 
detail. Nonetheless, based on the description herein, persons with the present invention, gatekeeper/entry handler com- 
of ordinary skill in the art will appreciate a wide variety of 35 ponent 110 checks for the presence of a session token in the 
configurations in accordance with the present invention in incoming request. Use of session tokens is described in 
which non-browser clients, automated agents or other sys- greater detail below; however, in short, a session token may 
terns interact with enterprise applications and/or resources be, any data supplied to the client entity for use in uniquely 
190 and the security architecture using any of a variety of identifying an associated session. In general, preferred ses- 
information resource identification schemes. 40 s ion token implementations are cryptographically secured 
Focusing then on an exemplary browser-type client entity, and include facilities, such as expiration or mapping to a 
browser 170 requests access to one or more of enterprise particular connection, to limit risk of replay attack and/or 
applications and/or resources 190 (e.g., information resource spoofing. Some session token implementations may encode 
191) by presenting an URL to gatekeeper/entry handler session, principal, and/or trust level information. Some 
component 110, which acts as a point of entry for client 45 session token implementations may employ cookies, URL 
entities requesting access to applications and/or resources encoding, or other similar techniques for binding to incom- 
controlled by the security architecture. Gatekeeper/entry ing requests. 

handler component 110 receives the request as a proxy for In some configurations, session tokens are employed to 

the requested resource. In some configurations, a combined facilitate session continuity and to allow the security archi- 

gatekeeper/entry handler instance is provided, while in 50 tecture to associate prior authentication of login credentials 

others, separate and/or multiple instances are provided with with an incoming access request. In one utilization, session 

functionally identical interfaces to other components of the tokens are issued to client entities as part of an interaction 

security architecture. In some configurations, multiple with the security architecture and are thereafter presented 

instances of entry handler functionality (e.g., interception of with access requests. In some configurations, new session 

inbound requests and collection of environment 55 tokens (each corresponding to a single session) are issued to 

information) are provided. For example, one or more client entity on each credential level change. In other 

instances for each of several connection types (e.g., dialup, configurations, a session token may remain the same even as 

WAN, etc.) may be employed. One or more instances of credential levels are changed. Session continuity means the 

gatekeeper functionality (e.g., allowing access for autho- maintenance of coherent session stale across one or more 

rized requests and otherwise denying or initiating appropri- go interactions between an entity and an information environ- 

ate responsive action) may also be provided. Configurations ment. 

and functional decompositions suitable to a particular envi- Components of session state (e.g., in some configurations, 
ronment and expected load requirements will be appreciated principal id, session id, authenticated trust level, group ids 
by persons of ordinary skill in the art. and/or roles, creation time, expiration time, etc.) are main- 
Entry handler functionality (e.g., in gatekeeper/entry han- 65 tained or advanced throughout the duration of a session, 
dler component 110) ascertains much of the requesting Typically, aspects of session state are represented internally 
client's environment information. For example, for dial-up by the security architecture and a session token (e.g., a 
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session id encoded in a cryptographically secured session 
token) allows the security architecture to reference into the 
internal representation. However, in some configurations, at 
least some aspects of session state may be represented or 
duplicated in the session token. For example, a principal id 
and current trust level are encoded in one realization of a 
cryptographically secured session credential and associated 
session token or cookie. In general, a variety of facilities, 
such as cookies, can be used to maintain state across a series 
of protocol interactions, such as HTTP transactions, that do 
not otherwise support persistent session state. 

Referring again to FIG. 1, if a session token is present in 
the incoming request, gatekeeper/entry handler component 
110 resolves the token to a session object. Alternatively, if no 
session token is present or if a session token is invalid, 
gatekeeper/entry handler component 110 establishes a new 
session (2). In an exemplary configuration in accordance 
with FIG. 1, session management component 160 allocates 
a new session and supplies associated default session cre- 
dentials (2) based on the requested information resource and 
environment information. Note that a session is created 
irrespective of authentication status or identity, although 
some implementations may refuse to even allocate a session 
based on particular information resource requests and/or 
environment information. Given a session object, which 
may be resolved from a received session token or newly 
allocated, gatekeeper/entry handler component 110 interacts 
(3, 4) with authorization component 140 to determine 
whether the requested access is authorized. For some 
requested accesses and security policies (e.g., anonymous 
ftp access to certain archives), even a session without 
authenticated login credentials (trust level-0) may be autho- 
rized. For others, a more substantial trust level may be 
required. 

Gatekeeper/entry handler component 110 supplies autho- 
rization component 140 with an identifier for the requested 
resource (e.g., the requested URL) and an identifier for the 
associated session. Preferably, the associated session iden- 
tifier is cryptographically secured (e.g., as a signed session 
credential). In some configurations, the signed session cre- 
dential is obtained from the corresponding session object. In 
the case of a pre-existing session, the signed session cre- 
dential may be obtained using a received session token. In 
any case, authorization component 140 receives (3) the 
requested resource and session identifiers and responds (4) 
in accordance with the trust level requirement of the 
requested resource. In configurations for which sensitivity to 
a changing environment is desired, environment information 
may also be supplied to authorization component 140. In an 
exemplary configuration, authorization component 140 
responds with an ALLOW, REDIRECT, or REFUSE 
response based on the sufficiency of a current trust level. In 
some configurations, authorization component 140 dynami- 
cally calculates a current trust level based on the signed 
session credentials and environment information. In others, 
authorization component 140 may base its ALLOW, 
REDIRECT, or REFUSE response on a "current" trust level 
previously associated with the signed session credentials: 
Generally, an access request with sufficient current trust 
level is ALLOWED and forwarded (14) without further 
authentication. An authorization request without proper 
parameters (e.g., without a specified information resource or 
without a properly secured session credential) may be 
REFUSED. Authorization requests associated with a client 
entity that has been blacklisted or for a resource for which 
the associated client entity cannot be authenticated using any 
available method to achieve the required trust level may also 
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be REFUSED. For example, a given security policy and 
associated trust level mappings may dictate a REFUSE 
response in response to an access request to a sensitive 
resource (such as financial data) by any client entity (even a 
5 browser supplying the,digital certificate for the CFO, and 
therefore presumably operating on behalf of the CEO) if the 
access request is received over a dial-up line and originates 
from an unknown number or is received outside of working 
hours. 

10 In general, there is an implicit, base level of environment 
inherent in an authenticated trust level; however, in some 
configurations, a particular authorization transaction may 
dig deeper into environment information before responding. 
For example, in configurations providing log-up 
capabilities, an authorization service will typically redirect 

15 to a login service if the trust level associated with current 
session credentials is insufficient for a requested access. 
However, for sensitive applications in such a configuration, 
an inadequate trust level may result in a REFUSED message 
rather than a log-up REDIRECT depending on the particular 

20 security policy implemented. 

A REDIRECT response is used to forward the access 
request to login component 120 so that sufficient login 
credentials may be obtained and authenticated to achieve the 
required trust level for the requested access. Note that in 

25 some configurations, both initial login credentialing and 
credential upgrade are provided using the REDIRECT facil- 
ity. In response to a REDIRECT response (4), gatekeeper/ 
entry handler component 110 redirects (5) browser 170 to 
login component 120. In one configuration, gatekeeper/entry 

30 handler component 110 issues a client-side redirect via 
HTTP location directive to forward the request to login 
component 120. Parameters such as required trust level, 
requested URL and credential passing method can be 
encoded in the redirect URL and supplied (6) by browser 

35 170 to login component 120. Alternatively, some parameters 
can be passed (5A) directly (e.g., through a HttpSession 
object) although a stateless configuration is preferred. 

A session token is passed to browser 170 in conjunction 
with the redirect (5) to login component 120. Based on the 

40 description herein, persons of ordinary skill in the art will 
appreciate a number of suitable mechanisms for passing the 
session token, including those based on cookies and URL 
encoding. Preferably, mechanisms employed are based on 
facifities provided by commercially available browsers (e.g., 

45 in accordance with HTML 3.x, 4,x or other de-facto 
standards), although customized or plug-in facilities for 
receiving and supplying session token may be employed. In 
one suitable configuration, the session token is cryptographi- 
cally secured and encoded in a cookie placed at browser 170 

50 using a set cookie directive embedded in the redirect. Other 
configurations may use a less persistent session identifica- 
tion method, such as passing an identifier or session token in 
the redirect URL without storage at browser 170. Still other 
configurations may transmit a session token, a session 

55 credential, or identifier such as a session handle for storage 
in a medium such as a smart card. In configurations provid- 
ing credential upgrade, persistent session identification 
methods are generally preferred, even for a not yet authen- 
ticated client entity, for consistency of approach. Note that 

60 although the identity of the client entity may not be authen- 
ticated to a sufficient level of trust, the redirected request 
includes a session token that at least identifies the session. 
Other configurations may omit the binding of session tokens 
to sessions of not yet authenticated client entities, though 

65 with some increase in complexity of login component 120. 
Browser 170 sends (6) login component 120 a new access 
request using the URL specified in the redirect from 
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gatekeeper/entry handler component 110. In configurations personal digital certificate (such as those issued by 

employing cookies as a medium for passing session tokens, Verisign™, Thwate, Entrust or other certificate authority) 

the new access request will include tie cookie and therefore may be obtained from a browser 170 using an HTTP 

the session token. Note that in configurations in which the certificate request. Although credentials may be transacted 

security architecture controls access to resources in several 5 in a variety of ways, credentials are typically obtained from 

domains, care should be exercised to select a tag or tags for a user. Typically, the obtaining is indirect by asking the 

the cookie such that it will be provided through normal user's browser to complete the negotiation process. In such 

operation of the browser in subsequent accesses to any of the configurations, certificate -based authentication may be 

several domains. Persons of ordinary skill in the art will transparent to the user. In some configurations, further 

appreciate suitable tagging techniques, including the use of 30 authentication can be performed by using information 

multiple cookies. Login component 120 receives the access encoded within the certificate to query a certificate authority 

request and determines an appropriate authentication for current status or a lookup to an authentication database 

scheme based on mapping rules that identify those authen- may be performed for more detailed requirements. In an 

tication schemes which are sufficient to achieve a given trust exemplary configuration, the more detailed information 

level. Preferably, the mapping rules are a function of envi- 35 could relate to session environment or could force an 

ronment information. In some configurations, mapping rules additional name/password authentication as part of the cer- 

are implemented as fuzzy sets wherein acceptable authen- tificate authentication chain. In a particular implementation 

tication schemes are a function of required trust level and such facilities can be provided by mapping rule encodings 

environment information. In this way, environment affects that require successful authentication using multiple authen- 

the set of authentication schemes sufficient to meet a trust 20 tication methods to achieve a given trust level, 

level requirement. Once login credentials have been obtained by login com- 

Generally, mapping rule logic is typically evaluated ponent 120, they are supplied (11) to gatekeeper/entry 

before a user is challenged to authenticate. Mapping occurs handler component 110 for authentication. In configurations 

as a function of session environment and particulars of the in which both gatekeeper/entry handler component 110 and 

information resource for which access is requested. By 2 s login component 120 have access to a shared object such as 

evaluating the minimum trust level required by the target of the HttpSession object, login credential passing via the 

an access request, a service (e.g., a login service such as shared object is suitable. In other configurations, an HTTP 

provided by login component 120) derives a list of potential POST may be employed. In an exemplary configuration, the 

authentication methods. The service then checks current particular credential passing method is selected as part of the 

session environment against the allowed environment states 30 original HTTP redirect (e.g., encoded in the redirect URL) 

for each potential authentication method to trim the list although other configurations need not allow for a selection 

further. If there is no particular resource for which access is or may employ other facilities for selection of a credential 

being requested (e.g., if a user jumps straight to a sign-on passing method. 

page without requesting an access), the service will proceed Login component 120 also passes control of the access 

according to the lowest level of trust available consistent 35 request back to gatekeeper/entry handler component 110. In 

with session environment. Other configurations may employ an exemplary configuration, login component 120 issues a 

differing default behaviors. new HTTP request (11) specifying the originally requested 

In some configurations, login component 120 queries (7) URL, which has been stored in the HttpSession object. As 

authorization component 140 to identify the set of authen- before, gatekeeper/entry handler component 110 receives 

tication schemes that meet or exceed the required trust level 40 the request. Gatekeeper/entry handler component 110 

given a current environment. In other configurations, the extracts the login credentials from the request or from the 

mapping is performed by login component 120. In either HttpSession object and passes (12) the login credentials to 

case, login component 120 supplies (9) information to authentication component 130 for authentication. Authenti- 

browser 170 to allow the user to select from the suitable cation component 130 authenticates the login credential, and 

authentication schemes and to provide an associated login 45 if successful, queries (13) identification component 150 to 

credential. In some configurations, login component 120 establish a correspondence with a set of entity descriptors 

supplies browser 170 with a login page (e.g., HTML) that that uniquely identifies the requesting entity. In an exem- 

prompts the user for an application specific user ID and a plary configuration, entity descriptor types include: entity id, 

choice of authentication schemes. Interactions with browser system id (e.g., name/password), certificate, enigma id, 

170 depend on the set of credential types that, if 50 smartcard token, name/address, and phone. One or more of 

authenticated, would be sufficient to meet the trust level values may uniquely identify an entity and one or more 

requirement for access to the requested resource. For entity descriptor types may support multiple values (e.g., 

example, if more than one type of credential would be multiple digital certificates, name/password pairs, or phone 

sufficient, login component 120 may interactively allow a numbers per identity). Once the requesting entity has been 

user to select from amongst the credential types (e.g., using 55 identified (14), session parameters are updated (15) and 

any HTML-based dialog). Once a particular credential type session management component 160 supplies (16) session 

has been selected, login component 120 interacts with credentials. Preferably, session credentials are digitally- 

browser 170 to obtain an instance of the login credential to signed or otherwise cryptographically secured and returned 

establish the identity of the browser user. (17) to gatekeeper/entry handler component 110. 

Some credential types (e.g., username/password pairs, 60 Gatekeeper/entry handler component 110 again supplies 

onetime passwords, enigma challenge, etc) may be obtained (18) authorization component 140 with an identifier for the 

through an interactive process in which the user supplies the requested resource (e.g., the requested URL) and an iden- 

login credentials) entry into an HTML form browser 170 tifier for the associated session (e.g., the signed session 

POSTs form contents back to login component 120. Others credentials, authorization component 140 responds with an 

(e.g., digital certificates) may be supplied (10) for the client 65 ALLOW, REDIRECT, or REFUSE response based on the 

entity from browser 170, or in some configurations, may be sufficiency the session credentials (and underlying authen- 

obtained from or via an agent or certificate authority. A tication of login credentials) for the trust level required for 
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the requested access. Login credentials should now be 
sufficient for access to the requested resource and an 
ALLOW response is supplied (19) by authorization compo- 
nent 140. Gatekeeper/entry handler component 110 proxies 
the requested access (20, 21) to information resource 191 5 
and streams (22) results back to login component 120. Login 
component 120, in turn, streams (23) results back to browser 
170. 

In some embodiments in accordance with the present 
invention, session continuity is facilitated by supplying a jo 
session token to browser 170. For example in one 
configuration, login component 120 supplies a session token 
using a set cookie directive encoded with the results 
streamed (23) back to browser 170. In response, browser 
170 stores the cookie using a tag (typically a filename ^$ 
encoding). Browser 170 supplies the cookie (and the session 
token) with subsequent access requests based on a corre- 
spondence between the tag and the requested resource. 
Typically, the correspondence is based on the second-level 
domain (e.g., sun.com) in which the requested resource is 2 o 
hosted, although nth-level domains or other resource iden- 
tification and session token associating schemes may be 
employed. In configurations in which the security architec- 
ture controls access to multiple domains across which a 
spanning single sign-on is desired, multiple cookies may be 2 s 
employed. 

Although the encoding of session tokens using cookies is 
presently preferred, in part because cookie facilities are 
widely supported and reasonably well accepted, other facili- 
ties may be employed to establish session continuity. For 30 
example, alternative URL encodings and/or custom or plug- 
in support for session identifier receipt, storage and supply 
may be employed. Also, some configurations may employ 
lower-level session identifiers, e.g., as provided by a par- 
ticular connection type such as trusted caller id information 35 
or as associated with a low-level line encryption or virtual 
private network infrastructure. As such facilities are likely to 
be connection- type specific, it is envisioned that they may be 
used in conjunction with other session identifier facilities 
described above, e.g., session tokens encoded in cookies. In 40 
one configuration, the unique Ethernet MAC address asso- 
ciated with a network interface card may be employed as a 
session handle. The MAC address is then used to associate 
with a particular set of session credentials maintained by a 
central authority. In general the representation of a session 45 
handle can take may forms. 

Referring again to FIG. 1, subsequent access requests 
(e.g., access request 1A) include a previously assigned 
session token. As described above, gatekeeper/entry handler 
component 110 uses the session token, if provided to resolve 50 
a session object containing session credentials, and to deter- 
mine whether previously authenticated credentials are suf- 
ficient for the requested access. As described above, autho- 
rization component 140 may be queried using session 
credentials and an identifier for the requested resource to 55 
determine sufficiency of previously authenticated creden- 
tials. In some configurations, sufficiency is determined using 
trust level mappings as described above. Depending on the 
information resource to which access is requested, and in 
some configurations depending on current session environ- 60 
ment information, access request 1A may or may not have 
associated previously authenticated credentials sufficient to 
support the requested access. In the case of an access request 
1A having a trust level requirement commensurate with 
previously obtained and authenticated credentials (i.e., an 65 
access request for which no additional credentials need be 
obtained via login component 120), the access request is 
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proxied (20) and results (21) are streamed directly (23A) 
back to browser 170. In some configurations, gatekeeper/ 
entry handler component 110 supplies an updated session 
token using a set cookie directive encoded with the results 
streamed (23 A) back to browser 170. An updated session 
token, if supplied, resolves to the same session object as the 
session token replaced. For example, in some 
configurations, both session tokens encode a same session 
handle, although other aspects associated with session token 
security such as expiration may be updated. In other 
configurations, results (21) are streamed (23 A) back to 
browser 170 without an updated session token. In such 
configurations, the previously supplied session token 
remains valid until expired or otherwise invalidated. Some 
variations may employ a session token refresh interval. 

Depending on the information resource to which access is 
requested, previously obtained and authenticated login cre- 
dentials may be insufficient for the trust level requirement 
associated with requested access 1A. As before, authoriza- 
tion component 140 supplies gatekeeper/entry handler com- 
ponent 110 with an ALLOW, REDIRECT or REFUSE 
response based on the trust level accorded based on the 
previously obtained and authenticated login credentials and 
on the trust level requirement associated with requested 
access 1A, Advantageously, authorization of individual 
access requests is streamlined by the encoding of trust level 
in a cryptographically secured session credential or token. In 
the case of insufficient credentials, a REDIRECT response is 
supplied and gatekeeper/entry handler component 110 again 
redirects (5) browser 170 to login component 120. Addi- 
tional login credentials are obtained as described above with 
reference to initial credentials. Upon successful 
authentication, access request is proxied (20) and results 
(21) are streamed (23 A) back to browser 170. 

Preferably, gatekeeper/entry handler component 110 sup- 
plies an updated session token using a set cookie directive 
encoded with the results streamed (23 A) back to browser 
170. An updated session token, if supplied, resolves to the 
same session object as the session token replaced. As a 
result, session state (including e.g., identity mappings, 
authorizations, roles, permissions, environmental variables, 
etc.) is maintained through the credential level change. 
However, in the case of a credential upgrade, the session 
object now encodes a login credential successfully authen- 
ticated to achieve a higher trust level. In one advantageous 
configuration, the achieved (higher) trust level is encoded in 
a cryptographically secured session token representation as 
a cookie streamed (23A) back to browser 170 with results 
(21). 

FIG. 2 illustrates operation of an exemplary security 
architecture providing a single sign-on facility with trust 
level mapping to authentication requirements. As before, an 
access request is received (201) from a client entity. If the 
request does not contain a session identifier (e.g., a session 
key or token) or if the request can otherwise be reliably 
associated with a session maintained by the security 
architecture, a new session is created (202). A trust level 
requirement is determined for access to the requested 
resource in the context of the requesting session environ- 
ment. In some configurations, as described above, the deter- 
mination is performed by an authorization service such as 
authorization component 140 Given a trust level 
requirement, current session credentials are evaluated (203) 
in the context of session environment information to deter- 
mine whether the previously supplied login credentials are 
sufficient to achieve the required trust level. In one advan- 
tageous realization of session credentials and tokens, a 
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cryptographically secured encoding of trust level allows (206) to a credential gathering service (e.g., login compo- 

autborization to be confirmed without involvement of an nent 120). The credential gathering service receives (207) 

authentication service (e.g., with re authentication of login the redirected access and obtains (208) a trust level require - 

credentials). In the case of a newly created (202) session, the ment for the requested access. In some configurations, the 

authorization evidenced by session credentials will typically 5 trust level requirement may be passed with the redirected 

be insufficient, although some security policies may allow access or otherwise associated with the redirected access, in 

anonymous access to certain resources. others the trust level requirement may be re -obtained from 

For a pre-existing session, i.e., for an access request that an authorization service such as authorization component 
can be reliably associated with a persistent session by a 140. A trust level requirement is mapped (209) to at least one 
cryptographically secured session token or otherwise, ses- JQ authentication scheme sufficient to achieve the requirement 
sion credentials may or may not be sufficient for access to based on current trust level mappings and, if employed in the 
the currently requested resource. For example, after a first map ping rules, based on current environment information, 
access, the identity of an entity accessing resources con- Assuming that at least one authentication scheme is avail- 
trolled by the security architecture wiU be authenticated to a able ^ if successfulj support the required trust tevcl> 
trust level sufficient for that access. Depending on the trust ^ credentials of that t are obtained (210) for me entil 
level requirements of a subsequent access and in some afld aulhenticaled (211) . Some cred ential types (e.g., 
configurations, depending on then current trust level map- , , v / t . J • 
ping rules and environment information, the level of tn£t ^™me/ P assword ?™>™ U ™ P ass h words > t eni S ma 
associated with a current session (e.g., as evidenced by challenge, etc) may be obtained through an interactive 
current session credentials) may or may not be sufficient for process in which a principal (e^g a human user I supplies the 
the subsequent access. In situations for which a current level 20 credential(s) entry in an HTML form and POSTs form 
of trust (e.g., resulting from prior authentication of login contents back to the credential gathering service. Others 
credentials for an entity associated with the session) is ( e -g*> certificates) may be obtained for the client entity from 
sufficient for later access to the same or to another infor- an agent or authority. For example, a personal digital cer- 
mation resource, access is allowed without additional tificate (such as those issued by Verisign™, Thwate, Entrust 
authentication. For example, in some security architectures 25 or other certificate authority) may be obtained from a 
in accordance with the present invention, the security archi- browser using an HTTP certificate request. In some 
tecture proxies (204) the request to the requested informa- configurations, a choice of credential types may be provided 
tion resource and streams (205) a resulting response back to and user may select from a set of credential types sufficient 
the requesting client entity. for the requested access. Once appropriate login credentials 

As described elsewhere herein, sufficiency of current 30 have been obtained and authenticated, the session corre- 

session credentials is determined using mapping rules that, sponding to the requested access is updated (213) to reflect 

in some realizations, include environment information. In the new authenticated session credentials. The now suffi- 

general, current session credentials may be insufficient (1) ciently authorized request is proxied (204) and results are 

because the identity of the requesting client has not yet been streamed back (205) to the requesting client entity. Updated 

authenticated (e.g., in a first access situation), (2) because of 35 or refreshed session credentials are typically supplied as a 

a higher trust level requirement for the requested access, or session token (e.g., a cookie) encoded with the streamed 

(3) because of a change in mapping rules or environment results. 

that causes a previously sufficient credential no longer be FIG. 3 illustrates interactions between functional compo- 

sufficient for a particular trust level. Whatever the reason for nents in an exemplary functional decomposition of a secu- 

the insufficiency, a request corresponding to a session and 40 rity architecture. An on-line order processing transaction is 

client entity that is insufficiently authenticated, and that is exemplary and functional boundaries are merely illustrative, 

therefore not authorized, is passed to a facility for obtaining Based on the description herein, a wide variety of suitable 

credentials of a type that, if authenticated, will support the enterprise information environments and functional decom- 

required trust level. positions in accordance with the appended claims will be 

Typically, session credentials and/or an associated session 45 appreciated by persons of ordinary skill in the art. 

token encode an expiration time (see description, above, of In the configuration of FIG. 3, application and central 

FIG. 4). In such configurations, a previously suflcient security portions (321 and 322, respectively) of the security 

session credential is insufficient after its expiration. In some architecture are illustrated. Of note, functional components 

configurations, session credentials are periodically refreshed of application security portion 321 are typically hosed as 

by reauthentication of the underlying login credentials. For 50 services on a first server environment, while functional 

example, in one implementation, a presented session token components of central security portion 322 are hosted as 

indicating expiration in less than five (5) minutes causes the services on a second server environment. In this way, most 

security architecture to re authenticate (not shown) underly- interactions amongst functional components occur within a 

ing login credentials stored in a corresponding SessionOb- single server environment and do not require network trans- 

ject (e.g., under the private key of authentication component 55 actions. In the configuration of FIG. 3, credentials associated 

130). Reauthentication typically results in a new session with a calling component (e.g., framework credentials asso- 

credential and associated trust level. Depending on then ciated with application security framework 303 or applica- 

instant mapping rules, the associated trust level may or may tion credentials associated with order management service 

not be sufficient. Also, reauthentication may fail if the login 312) are used to establish sufficient authorization for net- 

credentials have been invalidated, revoked or if the login 60 work transactions. Other configurations may be employed, 

credentials have expired. Assuming that reauthentication of however, the relatively small number of network transac- 

login credentials is successful, updated session credentials tions (e.g., authentication transaction 331 and optional value 

are issued, for example, by authentication component 130 passing transaction 332) tends to improve performance of 

and supplied (e.g., as a cookie encoded session token) to the the security architecture. Of note, authentication transaction 

client entity e.g., browser 170). 65 331 nee d only be performed on login credential authentica- 

Ref erring again to FIG. 2, a request corresponding to a tion (e.g., at initial sign -on or credential upgrade) or reau- 

session not authorized for a requested access is redirected thenticated (e.g., to refresh session credentials). Value pass- 
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ing transaction 332 provides an optional facility for passing service 312 and order processing proceeds in accordance 

values amongst multiple components of a distributed appli- with normal handling thereof. Additional accesses may be 

cation (e.g., a distributed implementation of order manage- required, e.g., to select delivery options or to confirm some 

ment service 312) wherein application credentials are used aspect of the order. Assuming that the additional accesses do 

to mediate storage and retrieval of values in a central 5 no t require a higher trust level, they will be passed to order 

registry. management service 312 based on the correspondence of 

User 301 interacts with browser 302 to place an order with session credentials with trust level requirements. 

order management service 312. An application security , f tion fa {hjQwn due {Q msufficient authorizat ion, 

framework 303 receives an access request including the ., iL . , . . . , , . ,. , w , 

77 f e.g., if the signed session credentials do not indicate that the 

order and, operating in conjunction with a variety of other in «r ■ *t ( l - j . _j 

y y 6 . . J . - ... . . «, 10 requesting entity is sufficiently authorized to access order 

services, provides a single sign-on faculty substantially as ^ ° 4 . j .* i • 
, .. . . « l j j . • . . management service 312, a logm credential gathering pro- 
described above. If the order does not include a session • j n j *u • j * r i i S 

... • j. cess is initiated. Based on the required trust level and on 

token or cannot be otherwise associated with corresponding , lL , , «- . 7 . 

... . .-I. • j • i rules that encode the sufficiency of authentication schemes, 

valid session credentials, then session credentials are , , t . . . , t . , ~ J ~ ni , 

, . , A ... t 4 . . p,^ - j . • i a logm credential is obtained from user 301 and/or browser 

obtained. As illustrated m FIG. 3, session credentials are -,<- - M & ™ . . . , , . . . . . c t » u * -e 

...... . . . ' . . *3 302. The obtauied logm credential is of a type that, it 

obtained using login credentials (e.g., a use rname/password t , . t , . «= ■ * * * *i_ * *i ■ • 

j- ■ i -n . v * ii r t authenticated, is sufficient to meet the trust level requirement 

pair, a digital certificate, etc.) Typically, an access request c . j . • ttt a * e 

F ' & . ... „ i * j i * for access to order management service 312. Aspects of an 

without session credentials will not have associated login , j i Ti_ * j -u j • 

, A . . A . _, j r n i j.-i/ exemplary credential gathering process are described m 

credentials. As a result, and default login credentials (e*. £ ^ above * Howev( f an ex a le> f, g . 3 

identity-anonymous) are used during initial phases of a 20 ob a vsemac/puam ^ pair . 0nC e 

single sign-on process. Nonetheless, in some configurations, . . . . u* • j *u j . » i 

, ? & . .\ , . . j . . P , login credentials are obtained, they are passed to central 

login credentials may be provided with an initial access •„ r i i rtJ * ✓ j -uT j u \ r *u »■ 

& w * • « • 1 . • j security framework 304 (as described above) for authenti- 

request. More typically, an initial access request is received . ' 4 . 4 . # > . . ~ A - ' . . 

i_ i- £. i iai * • cation by central authentication service 307 so that session 

by application security framework 303 without session _ , .-\ _ . , . • , # . o , B _ 0f . Uo 

« *• i m. t • . t . . credentials can be obtained, the requested access can be 

credentials or without prior presentation and authentication .... ... . • j o* j 

r . . . • *w . tl _ j authorized, and the order processing initiated. Signed ses- 

of login credentials sufficient to access the requested . \. . . . „ r . f . u- n 

& f , i . | . • a sion credentials, typically embodied as a cryptographically 

resource. In response to credential gathenng operations, a . ■ \ , . ■ j i ■ 

. t . • . -.u i- j i .u * secured session token that may be stored as a cookie, are 

subsequent request is made with login credentials that . . , t . J . 4 , n c ' , 

. . u «r ■ . *u *■ * j * . *u . * passed back to browser 302 with results of the requested 

purport to be sufficient, if authenticated, to meet the trust r . t . . , , ., ^ , 

f , ... . j ' . • access. In this way, subsequent access requests are identified 

level required for access to order management service 312. in 4 - ' .. ... . • , , 

y . ^ j - i ■ . . ■ 3U as part of a session and authorization may be quickly 

In such a case, session credentials are obtained by passing c . . . .... 

. . , . viwvuii « aiv ww ,.ivu u; F <«oiu 5 confirmed without unnecessary re-authentication, 

login credentials to a central security framework 304. J 

Authorization of application security framework 303 for Exemplary Implementations 
access to components of the central security portion 322 is 

checked by query to central authorization service 306. 35 In an exemplary embodiment, at least some of the above - 

Assuming that framework credentials evidence sufficient described components are implemented as servlets execut- 

authorization, login credentials are authenticated by central able in the context of a commercially-available web server 

authentication service 307. Central authentication service environment. For example, the Java™ Embedded Server 

307, in turn, interacts with central principal registry 310 to (JES) architecture with extensions for certificate handling, 

establish the identity and group membership of user 301 and 40 HyperText Transfer Protocol (HTTP), Simple Network 

with central session registry 311 to create a persistent Management Protocol (SNMP), Secure Sockets Layer 

session for subsequent accesses by user 301. Particulars of (SSL), extensible Markup Language (XML) grammar pro- 

the request are logged to central audit service 308 and, if cessing and security Access Control List (ACL) support 

authentication was successful, session credentials are available from Sun Microsystems, Inc. is one suitable envi- 

returned to application security framework 303. 4S ronment. Java and all Java-based marks and logos are 

Signed session credentials are presented to application trademarks or registered trademarks of Sun Microsystems, 
authorization service 313 together with an identifier for the Inc - me United States and other countries, 
requested resource and optionally with an identifier for a In general, the description herein is focused on aspects of 
particular function or facility of the requested resource. In a security architecture, rather than on peculiarities of :a 
response, application authorization service 313 checks the 50 particular implementation environment. It is envisioned that 
authorization of the principal (e.g., of user 301) associated security architectures in accordance with the teachings of the 
with the session credentials to access the requested resource. present invention may be implemented in the context of 
Application authorization service 313 interacts with appli- many commercially-available networked information ser- 
cation resource registry 314 to identify trust level require- vice environments, including web server environments, as 
ments for the requested resource (and in some 55 well as in custom environments and environments that in the 
configurations, for a particular function or facility of the future will be developed. However, to facilitate an under- 
requested resource) and determines the sufficiency of a standing of broad concepts using a specific exemplary 
current trust level evidenced by the session credential. Note environment, and without limitation, the description herein 
that trust level is assessed by inspection of the session may include terminology specific to the Java Embedded 
credential and without interaction with an authentication 60 Server (JES) architecture. Nonetheless, based on this 
service. In some configurations (e.g., as illustrated in FIG. description, persons of ordinary skill in the art will appre- 
3), group membership is also evaluated as part of the ciate implementations suitable for other environments. The 
authorization check. scope of the invention, as defined by the claims that follow, 

If the signed session credentials indicate that the request- is not limited to any specific implementation environment, 

ing entity, e.g., browser 302 on behalf of user 301, is 65 While the invention has been described with reference to 

sufficiently authorized to access order management service various embodiments, it will be understood that these 

312, a CreateOrder request is passed to order management embodiments are illustrative and that the scope of the 
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invention is not limited to them. Many variations, 
modifications, additions, and improvements are possible. 
For example, the set of authentication schemes described 
herein is illustrative and embodiments in accordance with 
the present invention may include others, including those 
that may be hereafter developed. If employed, rules mapping 
trust levels to authentication schemes may be encoded in a 
variety of ways depending on the particular implementation. 
In general, such mapping rules may be encoded as static or 
dynamic table associating trust level to authentication 
schemes. Alternatively, mapping rules may be encoded as 
predicates or in other declarative forms. Mapping rules may 
be encoded in a weighted logic or fuzzy set form. 
Additionally, particular mappings may depend environment 
information. Furthermore, evaluation of mapping rules may 
be performed in a variety of functional components such as 
an authorization service, a credential gathering service or a 
gatekeeper. Session continuity may be provided using cryp- 
tographically secure session tokens passed as cookies or by 
other mechanisms. 

In some configurations, a session token is a compact 
encrypted representation of at least selected contents of a 
session credential. Other compact representations corre- 
sponding to a session credential may be employed. 
Alternatively, the same representation of session credentials 
may be employed both within the security architecture and 
outside the security architecture (e.g., at a browser or other 
client). Suitable contents of a session credential (and session 
token, if employed) will be appreciated by persons of 
ordinary skill in the art based on the description herein of 
specific examples. 

More generally, plural instances may be provided for 
components described herein as a single instance. Finally, 
boundaries between various components, services, servlets, 
registries and frameworks are somewhat arbitrary, and par- 
ticular operations are illustrated in the context of specific 
illustrative configurations. Other allocations of functionality 
are envisioned and may fall within the scope of claims that 
follow. Structures and functionality presented as discrete 
components in the exemplary embodiments) may be imple- 
mented as a combined structure or component. These and 
other variations, modifications, additions, and improve- 
ments may fall within the scope of the invention as defined 
in the claims that follow. 

What is claimed is: 

1. A session credential for use in a security architecture 
controlling access to one or more information resources, the 
session credential comprising: 

a principal identifier uniquely identifying a principal; and 
an encoding of authorization accorded by the security 
architecture after prior authentication of a login cre- 
dential corresponding to the principal, 
the principal identifier and authorization encoding being 
cryptographically secured and allowing the security 
architecture to evaluate sufficiency of the authorization 
for access to the one or more information resources 
without re -authentication of the login credentials. 

2. A session credential as in claim 1, 
wherein the cryptographic securing includes encryption 

of at least the principal identifier and authorization 
encoding using a private key associated with the secu- 
rity architecture, 

3. A session credential as in claim 1, further comprising: 
an encrypted portion and an unencrypted portion; 
the unencrypted portion allowing contents of the session 

credential, including the principal identifier and autho- 
rization encoding, to be read without possession of a 
key; 
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the encrypted portion being encrypted with a private key 
associated with the security architecture and allowing 
authenticity of the unencrypted portion to be confirmed 
using a public key corresponding to the private key. 

4. A session credential as in claim 3, 
wherein the encrypted portion is supplied external to the 

security architecture as a session token that uniquely 
identifies a corresponding persistent session maintained 
by the security architecture. 

5. A session credential as in claim 4, 
wherein the session token is encoded as a cookie supplied 

to a browser; and 
wherein the cookie is included with access requests made 
by the browser targeting the one or more information 
resources. 

6. A session credential as in claim 3, 
wherein the cryptographic securing is by a private key 

possessed substantially only by an authentication com- 
ponent of the security architecture; and 
wherein authenticity of the cryptographically secured 
principal identifier and authorization encoding is veri- 
fiable by components other than the authentication 
component using a public key corresponding to the 
private key. 

7. A session credential as in claim 1, 
wherein the cryptographic securing includes a digital 

signature encompassing at least the principal identifier 
and authorization encoding and thereby allows authen- 
ticity of the principal identifier and authorization 
encoding to be confirmed using a public key. 
A session credential as in claim 1, further comprising: 
an expiration encoding. 

9. A session credential as in claim 1, further comprising: 
a session identifier. 

10. A session credential as in claim 1, further comprising: 
a group identifier. 

11. A session credential as in claim 1, further comprising: 
one or more additional elements selected from an expi- 
ration encoding; a session identifier; and a group 
identifier, 

the one or more additional elements also cryptographi- 
cally secured. 

12. A session token for transfer between a client entity 
operating on behalf of a principal and a security architecture 
controlling access to an information resource, the session 
token comprising: 

a principal identifier uniquely identifying the principal; 
and 

an indication of authorization level accorded by the 
security architecture after prior authentication of a 
login credential corresponding to the principal, 
the principal identifier and authorization level indication 
being cryptographically secured and allowing the secu- 
rity architecture to evaluate sufficiency of the authori- 
zation for access to the information resource without 
re-authentication of the login credentials. 

13. A session token as in claim 12, encoded as a cookie 
stored at a browser. 

14. A session token as in claim 12, placed at a browser in 
response to a set cookie directive by the security architec- 
ture. 

15. A session token as in claim 12, encoded for transfer to 
the client entity. 

16. A session token as in claim 12, encoded in a commu- 
nication medium as information in transit between the client 
entity and the security architecture. 
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17. A session token as in claim 12, 

wherein the client entity includes a browser; and 
wherein the session token is embodied as a cookie sup- 
plied to the browser by the security architecture and 
included with an access request made by the browser 
targeting the information resource. 

18. A method of providing authorization verification in a 
security architecture controlling access to one or more 
information resources, the method comprising: 

obtaining a login credential and authenticating a principal 
thereby; 

issuing a cryptographically secured session credential 
encoding at least an identifier for the principal and a 
first authorization accorded based on the authenticat- 
ing; and 

for plural requests for accesses to the one or more of the 
information resources, selectively allowing access 
based on sufficiency of the first authorization encoded 
by the cryptographically secured session credential for 
access to the one or more of the information resources, 
wherein the selective allowing is performed without 
additional login credential authenticating. 

19. A method as in claim 18, further comprising: 
digitally signing the session credential prior to issuance 

thereof; and 

prior to the selective allowing, verifying authenticity of 
the principal identifier and first authorization encoding 
using a public key. 

20. A method as in claim 18, further comprising: 
encrypting at least the identifier for the principal and the 

first authorization using a private key, 
the issued cryptographically secured session credential 
including at least the identifier for the principal and the 
first authorization in both encrypted and free text form; 
and 

prior to the selective allowing, verifying authenticity of 
the principal identifier and first authorization encoding 
using a public key corresponding to the private key. 

21. A method as in claim 20, further comprising: 
supplying the encrypted form of at least the identifier for 

the principal and the first authorization to a client entity 
external to the security architecture as a session token; 
the client entity presenting the session token with subse- 
quent access requests so that the security architecture 
may perform the selective allowing of the subsequent 
access requests without additional login credential 
authenticating. 

22. A method as in claim 21, 

wherein the client entity includes a browser; and 
wherein the session token is encoded as a cookie. 

23. A method as in claim 18, further comprising: 

on an access request for which the first authorization 
encoded by the cryptographically secured session cre- 
dential is insufficient, obtaining a second login creden- 
tial and authenticating the principal thereby: 
issuing a second cryptographically secured session 
credential encoding a second authorization accorded 
based on the authenticating by the second login 
credential; and 
selectively allowing the access request based on suffi- 
ciency of the second authorization encoded by the 
second cryptographically secured session credential. 

24. A method as in claim 18, 

wherein the cryptographically secured session credential 
also encodes an expiration; 
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the method further comprising: 
prior to the expiration, reauthenticating the principal by 

the first login credential; 
issuing a third cryptographically secured session cre- 
s dential encoding a third authorization accorded 

based on the authenticating by the first login creden- 
tial; and 

selectively allowing subsequent access requests based 
on sufficiency of the third authorization encoded by 
10 the third cryptographically secured session creden- 

tial. 

25. A method as in claim 24, 

wherein the first and third authorizations are equivalent. 

26. A method as in claim 24, 

15 wherein the first and third authorization are encoded as 
trust levels that differ in accordance with either or both 
of a changed session environment and changed map- 
pings of credential types to trust levels. 

27. A method as in claim 18, 

wherein the login credential is selected from a set of 
credential types including one or more of a usemame 
password pair, digital certificate, an encrypted creden- 
tials based on asymmetric, symmetric, public, private, 
or secret key technology, a one-time password, a bio- 
metric credential based on retinal scan, voice print, or 
finger print, and a possession based credential embod- 
ied in a smart card, Enigma card or physical key. 

28. A method as in claim 18, embodied as one or more 
computer program products including functionally descrip- 
tive information for directing a processor to perform the 
login credential obtaining and principal authenticating, the 
cryptographically secured session credential issuing, and the 
selectively allowing access based on sufficiency of the first 
authorization by the cryptographically secured session 
credential, the one or more computer program products 
encoded by or transmitted in at least one computer readable 
medium selected from the set of a disk, tape or other 
magnetic, optical, or electronic storage medium and a 
network, wireline, wireless or other communications 
medium. 

29. An information access control facility comprising: 
an application proxy for receiving an access request 

targeting one of a set of information resources, extract- 
ing a cryptographically secured session token from the 
access request, and selectively proxying the access 
request; 

means responsive to the application proxy for evaluating 
sufficiency of an authorization encoded in the crypto- 
graphically secured session token for access to the 
targeted information resource. 

30. An access control facility as in claim 29, further 
comprising: 

credential gathering means responsive to an insufficient 
55 zero or more login credentials associated with the 
session, the credential gathering means obtaining a 
login credential of type sufficient, if authenticated, to 
achieve a trust level requirement of the targeted infor- 
mation; and 

60 authentication means for receiving the obtained login 
credential, authenticating a principal thereby and issu- 
ing a session credential corresponding to the session 
token. 

31. An access control facility as in claim 29, further 
65 comprising: 

means for transferring the session token between the 
access control facility and the client entity. 
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32. An access control facility as in claim 29, embodied as medium and a network, wireline, wireless or other commu- 
a computer program product encoded by or transmitted in at nications medium, 
least one computer readable medium selected from the set of 

a disk, tape or other magnetic, optical, or electronic storage ***** 
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